Many techniques exist to “cluster” systems of servers for databases, web applications, etc., where the group of server systems is treated as a single entity. FIG. 1 illustrates a conventional group of server systems representing a single entity. A plurality of server systems 103.1-103.n is configured as a single group 101. From the perspective of a client 102, the group 101 of servers constitutes a single database or entity. When the client 102 wants to connect to one of the server systems 103.1-103.n of the group 101, any of the server systems 103.1-103.n are candidates for the client connection.
Occasionally, users of such systems wish to be able to automatically target a subset of the server systems 103.1-103.n so that only those server systems are affected by a particular set of client application requests. In one conventional solution, the client 102 requests a TCP/IP address for the server systems in the subset from a domain name server (DNS) (not shown). The DNS would be set up with lists that provide the server system TCP/IP addresses for a particular name, through which the subset of server systems can be accessed.
However, this solution has several drawbacks. First, for a typical DNS, the TCP/IP addresses of the server systems 103.1-103.n are given out to the client 102 in a round-robin manner without regard to whether or not the particular server system at the address is available and/or the server system has the capability to handle the client application's request. Second, once connected to the particular server system, the connection remains with that server system until a request to disconnect is received, without regard to whether or not the server system had the capacity to continue processing the client application's requests. This solution assumes that the client 102 disregards any server capacity feedback mechanisms. Third, if the client 102 did utilize the server capacity feedback mechanisms for workload balancing, the only information being returned from the server system would be capacity information for the group 101 as a whole, not just the subset of server systems. Eventually, requests would be sent to all server systems 103.1-103.n in the group 101.
In another solution, each server system of a subset would be defined with a unique “target” name that would be different from the name of the group 101, and probably have different TCP/IP access port numbers as well. This would permit the server feedback mechanisms to only report on the server systems of the subset. However, when a client application wants to access any or all of the server systems 103.1-103.n of the group 101, since there is no longer a common name for all of the server systems 103.1-103.n, there is no way for the client application to be able to get to any and all of the server systems 103.1-103.n in the group 101, unless the client application itself manages this aspect of the connection. In addition, any one server system can only participate in one and only one subset.
In both solutions, the sharing of data between the server systems in the group 101 is always a requirement whether a subset of the group of servers or the group as a whole is to be accessed.